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RECEIVED 

CENTRAL FAX CENTER 

JUL 2 6 2007 

Amendments to the Drawings; 

Please replace Figure 1 with a new Figure 1, attached, where labels 105 and 107 in the 
network element 100 are changed to 107 and 105 respectively. Support for this change is 
at least at paragraph [0017] of the specification (as previously amended). 
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RECEIVED 

CENTRAL FAX CENTER 

JUL 2 6 2007 

REMARKS 

The enclosed is responsive to Examiner's Office Action mailed on April 26, 2007, At 
the time Examiner mailed the Office Action claims 1-58 were pending. Claims 1-3, 5-21 and 
26-58 are rejected. Claims 4 and 22-25 are allowed. By way of the present response 
Applicant has: 1) amended claims 2-7, 12 f 34-39, 47-48, 53 and 57-58; 2) added no new 
claims; and 3) canceled claim 30. As such, claims 1-29 and 31-58 are now pending. No 
new matter has been added. Applicant thanks the Examiner for the allowed claims in this 
case. Applicant respectfully request reconsideration of the present application and the 
allowance of all claims now presented. 

z. Claim Rejections - 35 use 5102 

Claims 1, 12, and 13 are rejected under 35 U.S.C. 102(e) as being anticipated Miki 
et al., U.S. Patent No. 7,173,932 (hereinafter "Miki"). 

a. Overview of Mikl 

Miki discloses an access node run as a packet switching apparatus to accommodate a 
plurality of access methods. See Mfkl, col. 3, lines 45-47. Exemplary access methods 
contemplated by Miki are illustrated in prior art figure 20 for high-speed Internet Protocol 
(IP) connections, prior art figure 21 for low-speed IP connections, and figure 22 for mobile 
network IP connections. S^e Miki, Figs. 20-22. The Miki disclosure combines each of these 
access methods into one access node. Miki, Fig. 1; col. 5, lines 53-57. The reference 
accomplishes this using a pathfinding table that essentially maps inputs to outputs for 
tunneling in a core network. Specifically, the access node described in Miki maps input 
ports, input tunnel identifiers and input session identifier entries to output ports, output 
tunnel identifiers and output session identifier entries. See Miki, col. 3, lines 48-60; Figs, 3- 

App. No.: 10/600,192 -15- Atty. Docket No.: 4906.P140 

Reply to Office action of 4/26/07 



PAGE 16/27 * RCVD AT 7/26/2007 9:25:45 PM [Eastern Daylight Time] * SVR:USPT0-EFXRF-5/1 9 ' DNIS:2738300 * CSID:4087208383 * DURATION (mm-ss):M-34 



07/26/2007 18:29 FAX 4087208383 BSTZ LLP El 017 



4. However, the reference does not disclose converting an input of one type to an output of 
a different type. That is, the access node disclosed in the reference can cope (not convert 
between) a plurality of access methods. Miki, col. 3, lines 63-65. £e£ also Fig. 3, col. 7, 
lines 3-6 ( n [t]he data elements in the table shown in FIG. 3 are arranged in relation 
between the input to and the output from the access node AN11 apparatus in a general 
view"). The Miki reference, therefore, only describes switching and routing packets from a 
plurality of access methods where the functionality is combined into a single access node 
based on a pathfinding table. See exi . Fig. 5, col. 7, line 27 - col. 8 r line 35 (exemplary 
method of connecting using a DSL line). 

b. Independent claim 1 

The Office Action has rejected claim 1 under § 102 as being anticipated by Miki. 
Office Action, April 26, 2007, p. 2. Applicant respectfully disagrees and submits the 
following remarks in support of Applicant's position. 

Applicant submits that Miki does not disclose at least the following bolded limitations: 

1. A method in a network element comprising: 

converting Point to Point Protocol (PPP) protocol data units (PDUs) 
encapsulated according to different protocols Into PPP PDUs within a 
uniform encapsulation} and 

transmitting the uniformly encapsulated PPP PDUs. 

As discusses above, the Miki reference describes switching packets originating from a 
plurality of access methods from input to output through a tunnel in a core network. 
Applicant submits that this is not the same thing as ""converting Point to Point Protocol 
(PPP) protocol data units (PDUs) encapsulated according to different protocols 
into PPP PDUs within a uniform encapsulation" for the following independent reasons. 
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First, the Mlki reference does not disclose converting PPP PDUs of different protocol into PPP 
PDUs of a uniform protocol as required by claim 1. Miki describes a method of receiving 
inputs from different subscribers using different access methods (such as DSL, dial up and 
mobile network connections), but does not describe converting PPP PDUs of different 
protocol into PPP PDUs of a uniform protocol. In fact, nowhere in the Miki reference is the 
word "convert" even mentioned. That is because the reference is not concerned with 
converting PPP PDUs of different protocol into PPP PDUs of a uniform protocol as is required 
by claim 1. Instead, Miki teaches how to combine several access methods Into one access 
node (packet switching apparatus). The Miki reference switches and routes PPP packets 
from input to output using the same protocol. For example, the Point to Point Protocol over 
Ethernet on ATM (PPPoEoA) protocol used in the discussion of Fig. 5 is not converted to a 
PPPoE protocol as required by claim 2. Miki, Fig. 5, col. 7, line 24 - col. 8, line 35. 
Rather, the input and output protocol in this example are both PPPoEoA. See Miki, col. 8, 
lines 32-35 ("the example case of DSL access using PPPoEoA has been explained above"). 
While it Is true that the reference is not limited to the PPPoEoA protocol (see col. 8, lines 
32-35), it is also true that whatever protocol is used in the Miki example; that protocol is 
never converted to any other protocol during the method described in Miki. Accordingly, 
Applicant submits that the Miki reference does not disclose at least "converting Point to 
Point Protocol (PPP) protocol data units (PDUs) encapsulated according to 
different protocols Into PPP PDUs within a uniform encapsulation" as required by 
claim 1. 

For further support please see Figs. 1, 5; col. 7, line 27 - col. 8, line 35 (method of 
connecting over a DSL network), Rgs. 6, 7; col. 8, line 36 - col- 9, Iine3 (method of 
connecting over a telephone network), and Fig. 8, 9, col. 9, lines 4-31 (method of 
connecting over a mobile network), 
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In addition, Applicant respectfully submits that the Miki reference does not describe 
at least "transmitting the uniformly encapsulated PPP PDUs" as required by claim L 
Since the Mlki reference does not describe converting from different protocols to a uniform 
protocol as argued above, it logically follows that the Miki reference cannot describe 
transmitting the uniformly encapsulated PPP PDUs that were never converted. Accordingly, 
Applicant submits that the Miki reference does not disclose at least "transmitting the 
uniformly encapsulated PPP PDUs" as required by claim 1. 

As a result of the above discussion, Applicant submits that Miki does not anticipate 
claim 1 as asserted by the Office Action. Accordingly, Applicant respectfully requests 
withdrawal of the claim rejections. Further, Applicant submits that dependent claims 8-13 
depend upon claim 1, either directly or indirectly, and, are also not anticipated for the same 
reasons as independent claim 1. Accordingly, Applicant also respectfully requests 
withdrawal of these claim rejections. 

II. Claim Rejecti ons - 35 USC S103 

Claims 2, 3, 5-11 and 14-58 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Miki. 

a. Independent claim 2 

Independent claim 2 has been rejected under 35 U.S.C § 103 as being unpatentable 
over Miki in view of what i$ well known to a person of ordinary skill in the art- Office Action, 
p. 4. Applicant respectfully disagrees and submits the following remarks in support of 
Applicant's position. 

Applicant submits that Miki does not disclose at least the following bolded limitations: 
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2. A method in a network element comprising: 

using a Point to Point Protocol over Ethernet (PPPoE) session Identifier 
to track a first flow of PPP protocol data units (PDUs) encapsulated with a 
non-Ethernet protocol; 

converting each PDU of the first flow of PPP PDUs into PPPoE 
PDUs using the session Identifier : and 

converting each PDU of a second flow ofPPPoE PDUs with the 
session identifier Into PPP PDUs encapsulated with the non-Ethernet 
protocol. 

Applicant submits that the Miki reference does not describe "converting each PDU 
of the first flow of PPP PDUs into PPPoE PDUs using the session identifier" as 

required by claim 2. 

The Office Action admits, "Miki does not explicitly teach that converting each of a 
flow of PPPoE PDUs with a session identifier into a second flow of PPP PDUs encapsulated 
with the non-Ethernet protocol. The Office Action argues, however, that since Mikl teaches 
a plurality of interfaces (30-1 to 30-m In FIG. 2) to accept PPP PDUs in PPPoX, "it would 
have been obvious for one having ordinary skill in the art to provide an Ethernet input 
interface unit to accept PPP PDUs In PPPoE such that the output session processing unit 40 
converts each of a flow of PPPoE PDUs with a session identifier into a second flow of PPP 
PDUs encapsulated with the non-Ethernet protocol to transmit the flow via ATM output 
interface (50-m in FIG. 2) encapsulated with the non-Ethernet protocol. Office Action, p. 4. 

In response, Applicant challenges the Office Action's assertion that converting each 
of a flow of PPPoE PDUs with a session Identifier into a second flow of PPP PDUs 
encapsulated with the non-Ethernet protocol is well known and would have been obvious to 
one of ordinary skill in the art. First, the fact that the only reference cited in the Office 
Action's rejection of claim 2 is the Mikl reference which, as discussed above, does not 
disclose, teach, mention or suggest converting PPP PDUs of different protocol into PPP PDUs 
of a uniform protocol, militates in Applicant's favor. 
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Second, Applicant submits that the Office Action's assertion on page 4 
mischaracterizes the Miki Reference. The Office Action asserts that the Miki reference 
teaches converting between network protocols because it teaches a plurality of input 
interfaces 30-1 to 30-m corresponding to a plurality of output interfaces 50-1 to 50-m. 
While it is true that the Miki reference discloses a plurality of Input interfaces and output 
interfaces in figure 2, there is no discussion on converting the network protocol between the 
input and output interfaces. The Miki reference does not describe or suggest converting 
from one network protocol to another. Instead, Miki teaches routing various access 
methods (such as DSL, telephone or mobile connection) containing packets of various 
network protocols through a core network using the same network protocol. See supra 
(discussion with respect to Figs- 1 and 5). With reference to figure 2 of the Miki reference, 
the ATM input interface 30-m would be routed so that it reached ATM output interface 50-m 
using the pathfinding table. This is not the same thing as converting the PPPoA packet of 
input interface 30-m into a PPPoE packet to be output through Ethernet output interface 50- 
1. To accomplish this, Miki would have to disclose a proxy circuit such as PPPoX Proxy 
Module 201 contained in figure 2 of the Applicant's specification. Miki does not include a 
proxy module for converting PPP POUs of different protocol into PPP PDUs of a uniform 
protocol. 

The advantages of the conversion claimed by claim 2 is that it enables switching of 
both PPPoX and PPPoE traffic to be transmitted over a single media (i.e., it enables the 
switching network to be media agnostic with relation to transmission of PPPoX and PPPoE 
traffic). This also allows the switching network element becomes agnostic of the 
encapsulation the on subscriber side, thus providing more flexibility for traffic manipulation 
for services and increased efficiency and performance. For example, the PPPoX and PPPoE 
traffic can all be converted to PPPoE traffic and transmitted over GigE media which provides 
faster transmission at a relatively lower cost than other medias 
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Third, Applicant is not aware of any other reference or combination of references 
that disclose ^converting each PDU of the first flow of PPP PDUs Into PPPoE PDUs usino the 
session identifier" a$ required by claim 2. If this rejection is to be maintained, Applicant 
respectfully requests to be provided with a reference that indicates that such knowledge 
was well known or common knowledge within the art at the time of Applicant's invention. 1 

As a result, Applicant submits that it would not have been obvious to one of ordinary 
skill in the art, based on the Miki reference, to provide for "converting each PDU of the 
first flow of PPP PDUs into PPPoE PDUs using the session identifier" as required by 
claim 2. Additionally, Applicant submits that Miki fails to teach, describe or fairly suggest 
"converting each PDU of a second flow of PPPoE PDUs with the session identifier 
into PPP PDUs encapsulated with the non-Ethernet protocol'' for the same reasons as 
articulated above. 

Accordingly, Applicant respectfully submits that claim 2 is patentable over the Miki 
reference and requests withdrawal of the claim rejections. Applicant further submits that 
since dependent claims 14-17 depend upon claim 2, either directly or indirectly, they are 
also patentable over the Miki reference for the same reasons. Accordingly, Applicant 
respectfully requests the withdrawal of these claim rejections as well. 

b. independent claim 3 

The Office Action has rejected claim 3 under the same reasoning as claim 2. 
Therefore, Applicant submits that claim 3 is patentable over the cited reference for 



1 If Applicant challenges the Office Action's assertion that a feature is well known or common knowledge in th£ art, 
the examiner should cite a reference in support. MPHP § 2 1 44.03. 
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the same reasons as claim 2 is. That is, Applicant submits that the Mikl reference 
does not disclose at least the following bolded limitations: 



3. A method in a network element comprising: 

obtaining a Point to Point Protocol over Ethernet (PPPoE) session 
identifier for a first flow of PPP protocol data units (PDUs) that are 
encapsulated with a non-Ethernet protocol, wherein the first flow of PPP PDUs 
are received over a first port; 

converting each PPP PDU of the first flow into a converted first 
flow of PPPoE PDU s based on the session ide ntifier for the first flow: 

transmitting the converted first flow of PPPoE PDUs via a 
second po/t;_and 

converting each PPP PDU of a secondL flow of PPPoE PDUs 
received via the second port into a converted s econd flow of PPP 
PDUs encapsulated with the non-Ethernet protocol, wherein the 
second flow of PPPoE PDUs received via the second port corresponds 
to the PPPoE session identifier. 



Accordingly, Applicant respectfully requests withdrawal of the claim rejections 
as well as the rejections of claims 18-21 which depend on claim 3, either directly or 
Indirectly. 



c. Independent claim 5 



The Office Action has rejected claim 5 under the same reasoning as claims 2 
and 3. Therefore, Applicant submits that claim 5 is patentable over the cited 
reference for the same reasons as claims 2 and 3 are. That is, Applicant submits 
that the Miki reference does not disclose at least the following bolded limitations: 



5, A network comprising: 
a first network element 
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to receive a set of one or more flows of Point to Point Protocol over 
Ethernet CPPPoE^ and a set of one or more flow of Point to Point Protocol over 
non-Ethernet (PPPoX) traffic via a first port, 

to obtain a Point to Point Protocol over Ethernet (PPPoE) session 
identifier for each of the set of flows of PPPoX traffic, 

to convert each of the set of flows of PPPoX traffic into flows of 
PPPoE traffic In accordance with their session identifiers, 

to multiplex the flows of PPPoE traffic, 

to transmit the multiplexed PPPoE traffic via a second port; and 

a second network element coupled with the first network element, the 
second network element to receive the multiplexed PPPoE traffic and to 
transmit the multiplexed PPPoE flows to a set of one or more aggregators. 



Accordingly, Applicant respectfully requests withdrawal of the claim rejections 
as well as the rejections of claims 26-29 which depend on claim 3, either directly or 
indirectly. 



d. Independent claim 6 



The Office Action has rejected claim 6 under the same reasoning as claims 2- 
5. Accordingly, Applicant has amended claim 6 to include limitations from dependent 
claim 30 In order to make clear the distinction from the cited art. As a result, 
Applicant submits that claim 6, as amended, is now patentable over the cited art for 
the same reasons as claims 2-5 are. That is, Applicant submits that the Miki 
reference does not disclose at least the following bolded limitations: 



6, A network comprising: 

a set of one or more service provider points of presence (PoPs) to 
receive traffic that Includes Point to Point Protocol over non-Ethernet (PPPqXI 
traffic on a set of one or more subscriber side flows and to tunnel the traffic 
through a network cloud; 
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a PoP Major of the service provider coupled with the network cloud, 
the PoP Major to receive the PPPoX t raffic and to transmit the traffic as Point 
to Point ProtocoL over Ethernet (PE£s£}_traffic along a single media, wherein 
the set of one or more service pro vider PoPs are to convert each 
packet within the received traffic that is non-Et hernet traffic into 
PPPoE traffic bv matching an entry in a da ta structure that provides a 
PPPoE session identifier for each packe t to be converted: and 

a set of one or mora,a qqregators coupled with the PoP Major, the set 
of one or more aggregators to process the PPPoE traffic. 

Accordingly, Applicant respectfully requests withdrawal of the claim rejections 
as well as the rejections of claims 31-33 which depend on claim 3 f either directly or 
indirectly. 

e. Independent claims 7, 40, 48, and 53 

The same reasoning applies for rejected claims 7, 48 and 53 as does for 
claims 1-6. Accordingly, Applicant respectfully requests withdrawal of the claim 
rejections as well as the rejections of the associated dependent claims. The Office 
Action has failed to reject or allow claim 40. However, the same arguments with 
respect to claims 1-7, 48 and 53. Accordingly, Applicant respectfully requests 
withdrawal of the claim rejections as well as the rejections of all associated 
dependent claims. 

III. Allpwable Subject Matter 

Applicant would like to thank the Examiner for allowing claims 4 and 22-25. 
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CONCLUSION 



RECEIVED 

CENTRAL FAX CENTER 

JUL 2 6 2007 



Applicant respectfully submits that all rejections have been overcome and that all 
pending claims are in condition for allowance. If there are any additional charges, please 
Charge them to our Deposit Account Number 02-2666. If a telephone conference would 
facilitate the prosecution of this application, Examiner is invited to contact Matthew W. 
Hlndman at (408) 720-8300. 



Respectfully Submitted, 

BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP 



Date: 




Matthew W. Hindman 
Reg. No.; 57,396 
matthew_hindman@bstz.com 



1279 Oakmead Parkway 
Sunnyvale, CA 94085-4040 
(408) 720-8300 
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